home *** CD-ROM | disk | FTP | other *** search
/ TeX 1995 July / TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO / tex-k / tex-k-archive.past / tex-k-archive.gz / tex-k-archive / 000379_kb@cs.umb.edu_Mon Mar 14 00:51:03 1994.msg < prev    next >
Internet Message Format  |  1994-10-11  |  2KB
  1. Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA11507
  2.   (5.65c/IDA-1.4.4 for <tex-k-exp@cs.umb.edu>); Mon, 14 Mar 1994 05:51:04 -0500
  3. Received: by terminus.cs.umb.edu id AA28714
  4.   (5.65c/IDA-1.4.4 for tex-k); Mon, 14 Mar 1994 05:51:03 -0500
  5. Date: Mon, 14 Mar 1994 05:51:03 -0500
  6. From: "K. Berry" <kb@cs.umb.edu>
  7. Message-Id: <199403141051.AA28714@terminus.cs.umb.edu>
  8. To: tex-k@cs.umb.edu
  9. Subject: Re: Kpathsearch -- database searching
  10.  
  11.         setenv TEXINPUTS .:~/TeX/inputs:</usr/local/lib/texmf/ls-R>
  12.  
  13. That's an interesting idea (putting the db's into the search path).
  14. However, I'm not sure it's the best solution, since it requires the user
  15. to know whether or not there is a database, at path-specification time.
  16. If we can just dynamically use it if it's there, and not use it if it's
  17. not, with the same path specification, that seems preferable to me.
  18.  
  19. Instead, I was thinking of differentiating searches for files that must
  20. exist (PK's, TFM's, \input's) from those which need not (VF's in xdvi,
  21. \openin's).
  22.  
  23. In the former case, if a file can't be found in the db, we'll look for
  24. it on the filesystem (in case it's been created since after the db was
  25. last updated).
  26.  
  27. For the latter, if a file isn't in the db, we skip looking for it on the
  28. filesystem -- cmr10.vf isn't going to exist, and we don't want to expand
  29. $TEXMFROOT//fonts looking for it. (Except (of course) we look on the
  30. filesystem if the db file doesn't exist at all!)
  31.  
  32. It's true that this loses for files that can be dynamically generated
  33. (cmr10.600pk), since we will look on the filesystem for them, fail, then
  34. generate them. But this is happens only once (or until tomorrow, at
  35. most), since as soon as the db is regenerated (hmm, maybe maketexpk
  36. should regenerate the db?) it'll found that way.
  37.  
  38. On a typical run, which doesn't involve dynamically creating any files,
  39. there should be no lengthy filesystem operations given an up-to-date db.
  40.  
  41. By the way, there's a bug in the current sources -- if you have a file
  42. ./foo.tex and <system dir>/foo.tex, and foo.tex is in the db, your path
  43. spec is .:<sysdir>, and foo.tex is not the first file to be looked
  44. up, <sysdir>/foo.tex will be found instead of ./foo.tex.
  45.  
  46. K